\documentclass[11pt]{article}
\author{Ivan Bogouchev \and Ognyan Pertchev \and Gueorgui Tzotchev}
\usepackage[latin1]{inputenc}
\usepackage[francais]{babel}
\usepackage{graphicx}
\usepackage{verbatim}
\title{FOGE2 le retour}
\frenchspacing
\begin{document}
\maketitle

\pagebreak
\tableofcontents
\pagebreak

\section{Pr\'esentation du TER}

\subsection{Introduction (Foge d'origine)}

FOGE est une librairie Perl, d\'edi\'ee \`a la gestion de questionnaires,
destin\'es pour le WEB. La version d'origine \'etait \'ecrite par Christian
Queinnec pour faciliter le deploiment de questionnaires d'evaluation
des enseignements. Par la suite, deux \'etudiants - R\'emi Bantos et David
Haguenauer ont fait une r\'e\'ecriture orient\'ee objet visant \`a rendre la
librairie modulaire, facilitant l'ajout de nouvelles fonctionalit\'ees.

FOGE propose aux cr\'eateurs de questionnaires les objets et
fonctionnalit\'es suivantes:

\begin{enumerate}
\item objets repr\'esentant des questions: selon sa nature une question peut
etre repr\'esent\'ee sous forme d'un menu, d'un groupe de cases \`a cocher
(ou boutons radio) ou d'un textfiled (ou textarea).

\item objets repr\'esentant des sections - une section dans le vocabulaire
FOGE est une collection de questions, utilis\'ee pour regrouper des
questions concernant le m\^eme sujet.

\item objets repr\'esentant le formulaire - un formulaire dans le
vocabulaire FOGE est une collection de sections. Le formulaire est
l'objet principal d'un questionnaire, capable de servir la page HTML
du questionnaire, ins\'erer les r\'eponses dans une base de donn\'ees,
analyser les r\'eponses pour en extraire des statistiques.

\item objets repr\'esentant des statistiques associ\'ees au questions,
sections et formulaires, proposant plusieurs types de statistiques
(histogrames, camamberts, ...) choisies par le concepteur du
questionnaire.

\item gestion des droits d'effectuer certaines actions (visualiser le
questionnaire, r\'epondre, voir des diff\'erent type de statistiques) en
fonction de la date courrante, l'adresse ip de l'utilisateur ...

\end{enumerate}

Du point de vue des utilisateurs, FOGE offre les fonctionnalit\'es
suivantes: 

\begin{enumerate}
\item g\'en\'erer la page html visualisant le questionnaire en respectant la
norme HTML4 et utilisant les CSS. Les messages produits par FOGE (tels
que les noms des boutons, les messages d'erreur, la confirmation de
r\'eception d'une r\'eponse au questionnaire) peuvent etre traduits
automatiquement par FOGE. 

\item cr\'eer les tables SQL n\'ecessaires pour le stokage des r\'eponses.

\item ins\'erer dans la base de donn\'ees les r\'eponses (soummises via la page,
d\'ej\`a servie par FOGE) en veillant \`a ce que les r\'eponses respectent les
contraintes d\'efinies dans le questionnaire:
  \begin{enumerate}
  \item droit de r\'epondre (ip, utilisateur, date ....)
  \item r\'eponses au questions (balis\'ees) obligatoires
  \item r\'eponses conformes (\`a une expression r\'eguli\`ere par ex.)
  \end{enumerate}

\item extraire des diverses statistiques sur la r\'epartition des
r\'eponses. (dans FOGE2 les statistiques sont choisies par le concepteur
du questionnaire).

\end{enumerate}

\centerline{\includegraphics{formulaire}}
\subsection{But du TER}

On s'est propos\'e d'\'etendre les fonctionnalit\'es propos\'ees
par FOGE (surtout du point de vue utilisateur), pour permettre
d'effectuer des sondages exhaustives, ainsi que la
construction de toutes les statistques n\'ecessaires \`a l'analyse
adequate des donn\'ees.
(securit\'e)

On a donc rajouter les fonctionnalit\'es suivantes:

\begin{description}

\item[filtres] - un filtre permet de restreindre l'ensemble des soumissions
prises en compte par les diff\'erentes fonctionnalit\'es offertes par
FOGE. La restriction se fait en ne gardant que les soumissions
conformes \`a certains crit\`eres. 

\item[vues] - une vue permet de restreindre l'ensemble des questions pris en
compte par les diff\'erente fonctionnalit\'es offertes par
FOGE. L'utilisateur d\'efinit une vue, en choisissant les questions,
dont les r\'eponses l'int\'eressent.

\item[fiche-par-fiche] - la consultations d'un vote, en regroupant les
r\'eponses \`a toutes les questions qu'un utilisateur/\'etudiant \`a fait. La
consultation du vote fiche-par-fiche, exploite les sous-ensembles
d\'efinits, apr\`es le filtrage et la d\'efinition de la vue.

\item[securit\'e] - concentrer la gestion des droits d'acc\`es dans un module
d\'edi\'e \`a cet effet. D\'efinir formellement les diff\'erents types de
droits, actions et utilisateurs et les \'etapes de vie d'un
questionnaire.

\item[nouvelles statistiques] - les statistiques d\'edi\'ees \`a la
recherche d'interd\'ependances entre les r\'eponses des diff\'erentes
questions 

\item[nouveaux type de questions] - li\'ees logiquement (d\'ebloquer une des
questions seulement si la r\'eponse de telle autre questions est
conforme \`a certains crit\`eres.

\item[choisir les statistique au moment de la consultation] - permettre \`a
un utilisateur de choisir les statistiques qui lui conviennent, au moment
de la consultation.

\item[status] - vue d\'etaill\'e de l'\'etat du questionnaire

\item[adaptation] - adapter les parties exsitantes afin d'utiliser les nouvelles
fonctionnalit\'es: filtrage, vues, s\'ecurit\'e

\end{description}



\section{Les nouvelle fonctionnalit\'ees en d\'etailles}

Pour d\'ecrir en d\'etailles les extentions apport\'ees, expliquons
bri\`evement comment un script FOGE accompli ses fonctions de base
(servir la page html du questionnaire, ins\'erer les r\'eponses dans la
base de don\'ees et afficher les statistiques).

Un script FOGE est aussi un script CGI. En tant que tel, il est
lanc\'e par le serveur web et re\c coit dans son environnement plusieurs
informations (le query string des m\'ethodes GET et POST de HTTP, l'ip
d'o\`u le formulaire a \'et\'e invoq\'e ...).

Apr\'es avoir construit toutes les questions et sections et le formulaire
les contentant, le script FOGE invoque la m\'ethode main() du formulaire
(form->main()).

Ensuite en fonction des arguments pass\'es par le query string, le
formulaire d\'ecide de l'action qui lui est demand\'ee. En fonction de
l'action demand\'ee une des m\'ethodes serve(), handle\_submission() ou
print\_stats() sera appel\'ee. C'est pour \c ca qu'on les appelle des
\_actions\_.

Quelle que soit l'action demand\'ee, l'objet formulaire (de classe Form)
effectue une partie du travaille concernant le formulaire dans sa
totalit\'e et d\'el\'egue le reste du travaille \`a ses sections.  De m\^eme,
apr\`es avoir effectu\'e une partie du travaille la concernant en
totalit\'e, la section va d\'el\'eguer le reste du travaille au questions
qu'elle contient.

Cette approche modulaire permet de structurer le code et
rend ais\'e l'ajout de nouvelles fonctionnalit\'es.


\subsection{Filtres}

Le proc\'ed\'e de filtrage est un outil qui permet de rechercher
avec plus de pr\'ecisions les informations qui nous int\'eressent et de
mettre en evidance des r\'eslutats qui vont permettre par la suite
d'exploiter mieux les staistiques obtenues.
Les filtres diminuent l'ensemble de recherche, et montrent les
corr\'elations entre les diff\'erentes questions.
Le choix de filtres va affecter le mani\`ere dont les statistiques vont
être calcul\'es. De ce choix d\'epend, en grande partie, la p\'erception
des r\'esultats,

Un filtre est un objet qui se place entre la base de don\'ees est les
parties de FOGE qui en extraient des informations (statistiques,
consultations fiche-par-fiche). Il permet d'extraire des statistiques
pour un sous-ensemble des r\'eponses du questionnaire. Ce sous-ensemble
correspond \`a certains crit\`eres, choisis par l'utilisateur au moment de
la consultation des statistiques.

\subsubsection{Diff\'erents types de filtres}

Les diff\'erent types de filtres choisissent les sous-ensembles associ\'es
selon des crit\`eres diff\'erents. Le choix du filtre va affecter la
mani\`ere dont les statistiques vont \^etre calcul\'es. De ce choix d\'epend,
en grande partie, la p\'erception des r\'esultats.
Actuellement on a impl\'ement\'e deux filtres:

Le premier filtre permet de choisir les soumissions, en fonction des
addresses ip d'origine. Par exemple on aimerit savoir quelle
partie des \'etudiants ont utilis\'e les salles du CCE pour r\'epondre au
questionnaire et ensuite, voir quelle partie de ces \'etudiants a
affirmer vouloir travailler plus chez eux, qu'aux salles du CCE.

Le deuxim\`eme filtre, permet de choisir les soumissions, ayant donn\'e
telle ou telle r\'eponse \`a une ou \`a plusieurs ou \`a la totalit\'e des
questions du questionnaire. Cela permet de voir la r\'epartition des
r\'eponses dans la sous-population qui satisfait aux crit\`eres de
filtrage. 

(on n'a toujours pas fix\'e un nom pour les deux types de filtres:

    ?FilterIP, IPFilter, NetFilter (pour le filtrage des addresses)?

    ?FilterTemplate (pour filtrer en fonction des r\'eponses)?

)


\subsubsection{Constructions des filtres}

Le crit\`ere de filtrage, pour le FilterIP est une chaine d\'ecrivant une
addresse ip, o\`u on peut utiliser le caract\`ere '*' pour signifier un
groupe d'adresses ip. Par exemple pour les machines du CCE on
pourrait utiliser le filtre construit \`a l'aide de "134.157.116.*".

Pour construire le filtre template, FOGE sert \`a l'utilisateur qui veut
filtrer, la page HTML du questionnaire, telle qu'elle serait servie \`a
un \'etudiant pour remplir le questionnaire, mais avec quelques l\'eg\`eres
modifications: 
\begin{itemize}
  \item le questions \`a choix unique sont devenus des questions \`a
choix multiples. Donc l'utilisateurs remplira
  \item la r\'eponse \`a toutes les questions est facultative
\end{itemize}

\centerline{\includegraphics{filtre}}

Donc l'utilisateur r\'epondra au parties du questionnaire qui
l'int\'eressent, pour construiure un filtre qui va s\'el\'ectionner de la
base de donn\'ees seulement les soumissions, qui corr\'espondent \`a la
fa\c con dont l'utilisateur \`a rempli le questionnaire de construction du
filtre. 


\subsubsection{Impl\'ementation}

Pour chaque soumission FOGE stocke dans une table SQL ("foge\_answer") un
identificateur de la soumission, l'adresse ip et le nom du
questionnaire. Pour chaque section du questionnaire, il existe une
table SQL, qui contient les r\'eponses aux questions de la section. Le
premier \`atribut de cette relation est un identificateur r\'ef\'erencant
l'identificateur de la table "foge\_answer". Ainsi pour avoir les
r\'eponses qu'un \'etudiant a faites (et ensuite calculer les statistiques
dessus), on fait la jointure entre la table foge\_answer, et les tables
des sections su l'attribut id.
Donc pour filtrer, il nous suffit de garder dans la table foge\_answer
(actuellment on cr\'ee un table temporaire, qui masque foge\_answer) les
soumissions qui correspondent aux crit\`eres de filtrage.

Par exemple pour avoir toutes les soumissions, qui ont r\'epondu 'oui' \`a
la question 'Question1' de la section 'Section1', on d\'efinit la table
suivante:

\begin{verbatim}
CREATE TEMP TABLE foge\_answer
SELECT f.*
FROM foge\_answer f, Section1 s
WHERE f.enquiry="Poll" and f.id = s.id and s.Q1 = "oui";
\end{verbatim}

Donc le crit\`ere de filtrage est traduit en une expression WHERE du
langage SQL.


\subsection{Vues}

Une vue donne acces \`a un sous-ensemble des questions. Elle
permet de pr\'esenter \`a l'utilisateur (et au programmeur) diff\'erentes
perspectives du m\^eme questionnaire. Son utilit\'e se manifeste, surtout
lors du d\'epouillement des statistiques \`a des questionnaire longs, en
permettant de choisir de voir des statistiques sur une (petite) partie
des questions.

Apr\'es avoir d\'efinit la vue qui l'int\'eresse, l'utilisateur peut
visualiser les statistiques, consulter les r\'eponses aux questionnaire
fiche par fiche, ou d\'ecider de d\'efinir un filtre. En tout les cas les
fonctionnalit\'es offertes par FOGE, utiliseront l'ensemble des questions
d\'efinies dans la vue et non celles d\'efinies dans le formulaire.


\subsubsection{Construction des vues}

Actuellement on a impl\'ement\'e deux fa\c cons de construire une vue. 

La premi\`ere consiste \`a afficher la liste des questions du
formulaire, group\'ees par section et de donner \`a l'utilisateur la
possibilit\'e de choisir celles qui l'int\'eressent (\`a l'aide de cases \`a
cocher, affich\'ees \`a cot\'e des titres des questions).
Initialement toutes les cases sont choisies.


\centerline{\includegraphics{viewgen}}

\begin{verbatim}
<image>
* Section 1 __________ X
 - question 1.1 _____ X
 - question 1.2 _____ o

* Section 2 __________ o
 - question 2.1 _____ X
</image>
\end{verbatim}

L'utilisateur peut dess\'electionner les cases associ\'ees aux questions
qui ne l'int\'eressent pas ou dir\'ectement d\'ecider qu'il n'est pas int\'erress\'e par
toutes les questions d'une section et donc d\'ecocher la case
correspondant \`a la section.


La deuxi\`eme fa\c con de d\'efinir une vue est int\'egr\'ee \`a la consultations
des statistiques associ\'ees aux questions. Apr\`es avoir affich\'e la page des
statistiques pour les questions actuellement choisies, l'utilisateur
peut diminuer l'ensemble des questions (toujours \`a l'aide de cases \`a
cocher) et r\'eafficher la page des statistiques. C\`ad l'affichage des
statistiques et la d\'efinition de la vue sont fait dans la m\^eme page html.

\centerline{\includegraphics{statsnviews}}


\begin{verbatim}
<image>
 ___________________________
 * titre de la question _X_
 ----------------------------
 stat1 : stat2 : stat3 : ...
 ............................
 ____________________________
</image>
\end{verbatim}


\subsubsection{Impl\'ementation des vues}

Une vue est un objet perl, d\'efini dans le module View.pm. Un objet vue
est capable d'initialiser les attributs qui choisissent les questions
importantes, depuis les arguments pass\'es au script par la m\'ethode
POST. Une fois ses attributs intitialis\'es, l'objet est capable
d'affirmer quelles sections et questions font partie de la vue (\`a
travers les m\'ethodes contains\_question() et contains\_section()).

Donc d\'esormais, avant de d\'el\'eguer certainns actions \`a une de ses
sections, le formulaire v\'erifie que la section fait partie de la vue
que l'utilisateur a cr\'e\'ee, en invoquant la m\'ethode contains\_section()
de la vue. De m\^eme pour les sections, avant de d\'el\'eguer des actions \`a
une question, la section v\'erifie que la question appartient \`a la vue.


(Est-ce que une partie du code d'initialisation de la vue est
convenable ici?)


(Est-ce que une partie du code montrant l'app\`ele des m\'ethodes serve(),
handle\_submission(), etc des sections par le formulaire et des questions
par les sections est convenable ici)


\subsection{Fiche par Fiche}

La consultation fiche-par-fiche des r\'eponses aux
questionnaire nous permet de voir comment un utilisateur (un \'etudiant)
a rempli la totalit\'e du questionnaire. 

La visite des r\'eponses fiche par fiche est con\c cue afint d'exploiter
les fonctionnalit\'ees offertes par les filtres et les vues: c\`ad
l'ensemble des fiches sera compos\'e seulement des r\'eponses qui
satisfont au crit\`eres d\'efinis dans le filtre et chaque fiche
contiendra seulement les r\'eponses aux questions choisies par la vue.

\subsubsection{Comment consulter les r\'eponses}

L'examen du vote fiche par fiche est impl\'ement\'e comme une nouvelle
action effectu\'e par le formulaire. Donc il suffit d'invoquer le script
avec comme argument CGI action=fpf (meilleures propositions?). Bien
evidemment on peut avoir d\'eja d\'efinit un filtre et/ou une vue si
besoin est.



\subsection{Nouvelles statistiques}
On a rajout\'e un nouveau type de statistiques \`a la batterie de
statistiques que FOGE proposait d\'ej\`a - les stats croise\'es
(StatsCrossed.pm). Ce type de statistiques est con\c cu pour mettre \`a
l'\'evidence les interd\'ependences (ou montrer qu'il n'y en a pas) des
r\'eponses \`a une question en fonction des r\'eponses \`a une autre question.

\subsubsection{Interp\'etations de l'information fournie par les StatsCrossed}

\subsubsection{Impl\'ementation (D\'ependance du module GD)}


\subsection{Choix dynamique des statistiques}

Il s'agit de donner \`a l'utilisateur la possibilit\'e de choisir et
reconfigurer les statistiques affich\'ees lors de leur
consultation. Cela nous permet de choisir les statistiques en fonction de la
r\'epartition des r\'eponses. Des fois un camabert dit plus qu'un
histogramme.

\subsubsection{Impl\'ementation}



\subsection{La s\'ecurit\'e de FOGE}

FOGE est cr\'e\'e en raison d'être utilis\'e \`a travers des r\'eseaux TCP/IP,
internet en g\'en\'eral, et comme toute application expos\'ee \`a manipulation
d'une publique importante, il doit être bien prot\'eg\'e, c-\`a-d ne pas
laisser la possibilit\'e \`a une personne n'ayant pas les droits
n\'ecessaires de corrompre les donn\'ees et l'application elle-même.

Avant, les modules de FOGE assuraient une distinction basique des
types d'utilisateurs. Les v\'erifications d'identit\'e se faisaient dans
le module Form qui en g\'en\'eral avait pour but de construire le
formulaire et de traiter les diff\'erents types d'actions que le
questionnaire proposait. Bref, le processus d'identification n'\'etaient
que quelques petites fonctions dans le module Form qui v\'erifiaient que
l'adresse IP appartenait \`a un certain groupe autoris\'e. Ces fonctions
ne prenaient pas en compte le type de l'action demand\'ee, elles
retournaient ou "mourraient"...

L'extension dans cet aspect de FOGE consiste en un nouveau module,
nomm\'e SecurityAgent, ayant pour but d'\'etendre les possibilit\'es de
d\'efinition des droits d'acc\`es et de s'occuper des permissions des
usagers pendant les trois diff\'erentes \'etapes de la dur\'ee de vie d'un
questionnaire.

L'organisation des droits d'acc\`es est r\'ealis\'ee d'une mani\`ere un peu
semblable \`a celle d'unix, c-\`a-d une fois connect\'e un utilisateur est
authentifi\'e soit comme un utilisateur connu, soit comme faisant partie
d'une ou plusieurs groupes, chacun avec des droits sp\'ecifiques. Ainsi
le cr\'eateur du questionnaire peut sp\'ecifier les droits d'acc\`es pour
chaque adresse IP et/ou chaque utilisateur authentifi\'e par un login et
mot de passe, ces derniers obtenus \`a l'aide du protocole https, ou
simplement par une cl\'e de vote, qui assurera l'anonymat du client et
ses r\'eponses uniques (c-\`a-d qu'il n'a pas r\'epondu qu'une seule fois).

En g\'en\'eral il existent trois types d'usagers : - personne(s) avec des
droits d'administration (tous les droits) - personnes qui posent les
questions; eux ayant la possibilit\'e de consulter certaines ou toutes
les statistiques avant la date limite des soumissions.  - personnes
dont on veut l'opinion. (il se peut que la même personne poss\`ede 2
diff\'erentes identit\'es pour le formulaire - par exemple dans le cas
d'un formulaire ayant pour but de pr\'evoir les r\'esultats des \'elections,
le cr\'eateur du formulaire voudrait voter lui-aussi..)

La dur\'ee de vie d'un questionnaire \'etant limit\'ee en g\'en\'eral, on
distingue trois \'etapes de l'existence d'un questionnaire :

\'Etape 1 : Le questionnaire est mis au point, mais il n'est pas encore
autoris\'e \`a son audience \`a soumettre des r\'eponses. Seules certaines
personnes ont le droit de consulter et \'eventuellement d'apporter des
modifications au formulaire.  Ex. : Un professeur pourrait vouloir
ajouter une question portant sur l'examen final au formulaire
d'\'evaluation de la maîtrise, mais lors de la cr\'eation du formulaire
l'examen n'est pas encore prêt... Les modifications online ne sont pas
(encore) impl\'ement\'es.  \'Etape 2 : Le questionnaire est disponible aux
soumissions. Pendant ce temps les diff\'erents utilisateurs pourront
voir les r\'eponses, les statistiques simples, les statistiques avanc\'ees
ou ne rien voir, d\'ependant de leurs droits d'acc\`es.  \'Etape 3 : Les
soumissions finies, le formulaire est disponible aux analyses, mais
encore pas tous ont le droit de voir les r\'eponses \`a toutes les
questions.

La raison la plus importante d'apporter les modifications en cr\'eant ce
module n'est pas la besoin d'avoir un syst\`eme avanc\'e d'identification,
mais la complexit\'e de la mani\`ere de choisir quel utilisateur peut voir
quoi et dans quelle p\'eriode. Les droits d'un utilisateur peuvent
changer lors des trois \'etapes de l'existence d'un questionnaire donn\'e,
tandis que les droits d'un autre utilisateur du même type (voir types
plus haut) peuvent rester les mêmes ou changer diff\'eremment. Et même
si cela peut paraître rarement n\'ecessaire, il y a des cas o\`u une telle
flexibilit\'e aidera \`a favoriser des questions dont l'on ne voudrait pas
exposer les r\'eponses qu'\`a un certain groupe d'utilisateurs seulement.

Ayant s\'epar\'e de cette mani\`ere le processus d'\'evaluation des droits
d'acc\`es de la construction du formulaire rend la configuration des
droits facilement extensible et mieux param\'etrable.



\subsubsection{Comment d\'efinir les droits d'acc\`es?}

Les droits d'acc\`es sont d\'efinis dans le script de g\'en\'eration du
questionnaire lui-même, de mani\`ere qu'ils sont fig\'es dedans pour toute
la vie du questionnaire. Ils sont structur\'es sous forme de hachages et
tableaux imbriqu\'es.  En g\'en\'eral les droits se d\'efinissent en cr\'eant
une instance du module SecurityAgent. Cette instance s'initialise avec
les droits sp\'ecifi\'es comme arguments. Son constructeur la remplit avec
le reste des donn\'ees n\'ecessaires pour calculer quelles sont les
actions permises pour un utilisateur donn\'e \`a un instant donn\'e.  Il y
trois cat\'egories de utilisateurs : les super-utilisateurs, les
utilisateurs individuels, et les groupes. Les utilisateurs et les
super-utilisateurs sont authentifi\'es g\'en\'eralement par https. Les
groupes sont surtout des masques IP, mais rien n'empêche des
utilisateurs reconnus pas https d'être associ\'es \`a un groupe. Chaque
cat\'egorie est d\'efinie \`a l'aide d'un tableau. Les droits eux-mêmes sont
d\'efinis dans deux structures associatives (hachages), en faisant
correspondre \`a tout utilisateur et tout groupe d\'ej\`a d\'efinis un tableau
compos\'e de trois sous tableaux, un pour chaque
p\'eriode d\'efinie. Les tableaux imbriqu\'es contiennent les droits
explicitement d\'ecrits par des combinaisons des mots cl\'es : all, none,
submit, simple\_stats, all\_stats etc.  Les dates de d\'ebut et fin des
soumissions sont aussi donn\'ees en arguments.

Voici un exemple d'un appel du constructeur de SecurityAgent :

\begin{verbatim}
my $securisation = CGI::FOGE2::SecurityAgent->new 
    (
# utilisateurs privil\'egi\'es :
     superusers   => ("root","admin"),
# autres utilisateurs :
     users        => (addr\_ip1 => "user1", "user2" => "user2"),
# d\'efinition des droits d'acc\`es des utilisateurs :
     user_rights  => (
	 "user1"  => (("none"),                          # \'etape 1
                      ("submit","simple_stats"),         # \'etape 2
                      ("all_stats")                      # \'etape 3
                      ),
          "user2"   => (("none"),                 # \'etape1
                        ("all_stats"),            # \'etape 2
                        ("all_stats")             # \'etape 3
                       )
	             ),
# groupes :
     groups        => ("question_askers","replyers","gests", "127.0.0.1"),
# d\'efinition des droits d'acc\`es des groupes :
     group_rights  => (
	"question_askers" => (("all"),        # \'etape 1
                              ("all_stats"),  # \'etape 2
                              ("all_stats")   # \'etape 3
                             ),
	"replyers"        => (("none"),
                              ("submit","simple_stats"),
                              ("simple_stats")
                              ),
        "gests"           => (("none"), ("none"), ("simple_stats")),
        "127.0.0.1"       => (("all"),("all"),("all"))
                     ),
     submit_date0 => time(),
     submit_date1 => time()+1000,
);

\end{verbatim}

L'authentification des utilisateurs se fait soit en analysant
seulement leurs adresses IP, soit en leur demandant de fournir un nom
de login et mot de passe, ceci fait automatiquement par le serveur
Apache, il suffit de lui procurer le fichier .htaccess contenant la
directive « require valid-user » dans le r\'epertoire du script
g\'en\'erateur.


Pendant sa cr\'eation, l'instance de SecurityAgent analysera le
'QUERY\_STRING' et effectuera un contrôle , qui ne permettra aux
utilisateurs d'executer que les actions qui leur sont permises.
(Cela fixe le probl\`eme avec 'action=makesql')





\section{Exemple de session}
\begin{itemize}
  \item Se connecter
  \item Choix du filtre
  \item Choix de la vue
  \item Visualiser les statistiques
  \item Revisualiser les statistiques en diminuant l'ensemble des
  questions affich\'ees, et en choisissant des statistiques, autres que
  celle choisi par le concepteur
\end{itemize}

\section{Conclusion}

D'un cot\'e le travail r\'ealis\'e nous a confront\'e \`a diff\'erentes probl\`emes
qu'on a su r\'esoudre.  Le language de programmaton par
exemple.  Les connaissances en Perl de IB et GT se limitaient au cour
de Programmation Reticulaire de la Licence d'Informatique, alors que
OP d\'ebutait en Perl (Une des raisons de choisir ce sujet de TER \'etait
donc d'approfondir nos connaissence en perl, BD et programmation
CGI). De plus, Perl \'etant un language qui n'est pas adapt\'e "\`a la
lecture" (même avec le souci d'\'ecrire un code lisible et bien
comment\'e), la compr\'ehension du fonctionnement de Foge a demand\'e un
effort consid\'erable.

D'autre part le travail sur le TER rep\'esente pour nous une exp\'erience
profitable.  On a acquis une bonne maitruse de Perl, Postgres et
Apache.  On a su r\'especter les contraites li\'es \`a la r\'esolution d'un
probl\`eme concret (contrainte temporelle, de lanquage, d'integration du
code). C'\'etait aussi l'occasion de travailler en equipe - discuter,
combiner de diff\'erentes solutions, trouver le meilleure. Et
finalement on a eu la possibilit\'e da travailler sur un "vrai"
logiciel, de comprendre, d'am\'eliorer, et cela sous la direction de son
concepteur!

***********************

On a m\^eme \'et\'e confront\'es \`a un bug dans apache
"http://nagoya.apache.org/bugzilla/show\_bug.cgi?id=22030", qui se
manifeste lorsque le script produit beaucoup de messages de controle
vers le fichier de log du serveur.

\end{document}
